Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hookup!newshost.marcam.com!news.mathworks.com!newsfeed.internetmci.com!news.uoregon.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!Germany.EU.net!news.dfn.de!gina.zfn.uni-bremen.de!marvin.pc-labor.uni-bremen.de!news.uni-stuttgart.de!news.rhrz.uni-bonn.de!ignatios From: ignatios@cs.uni-bonn.de (Ignatios Souvatzis) Newsgroups: comp.protocols.ppp,news.answers,comp.answers Subject: comp.protocols.ppp part4 of 8 of frequently wanted information Supersedes: Followup-To: poster Date: 26 Jul 1995 18:24:43 GMT Organization: computer science department, university of Bonn, Germany Lines: 218 Approved: news-answers-request@MIT.Edu Expires: 23 Aug 1995 18:20:02 GMT Message-ID: NNTP-Posting-Host: theory.cs.uni-bonn.de Summary: This document contains information about the Internet Point-to-Point Protocol, including a bibliography, a list of public domain and commercial software and hardware implementations, a section on configuration hints and a list of frequently asked questions and answers on them. It should be read by anybody interested in connecting to Internet via serial lines, and by anybody wanting to post to comp.protocols.ppp (before he/she does it!) Xref: senator-bedfellow.mit.edu comp.protocols.ppp:11716 news.answers:49350 comp.answers:13322 Archive-name: ppp-faq/part4 Version: $Revision: 3.12 $ Last-modified: $Date: 95/02/06 20:10:10 $ URL: http://cs.uni-bonn.de/ppp/part4.html PPP questions and answers 4. MISC. PPP QUESTIONS WITH ANSWERS Does somebody have a patent on PPP? Is it possible to use PPP as link layer in ISDN? My ppp does infinite configuration negotiation. What's wrong? My ppp gets strange configure rejects. What's wrong? What is Asychronous HDLC? 4.1 Does somebody have a patent on PPP? From: emv@msen.com (Edward Vielmetti) Newsgroups: comp.protocols.tcp-ip,comp.unix.sysv386,comp.protocols.ppp Subject: Re: Public domain PPP for SCO 2.0?? Date: 8 Dec 1992 06:04:52 GMT [Somebody] wrote: Doesn't matter. I just read (in another newsgroup) that DEC has a patent on PPP, and is asking $5000 for a license. That means no public domain PPP, and a rapidly increasing reluctance to support it from OEMs. Stick with SLIP until something better comes along. This is *not* true. DEC has a patent application outstanding for the negotiation of a 48 bit checksum which might be used in one of the option negotiation phases. It is not an essential part of PPP; many implementations currently do not use this little tiny algorithm in the way they work, and they work just fine. There is no indication that the 48 bit FCS will be accepted or standardized on by the IETF - from my reading of the mailing lists traffic that is unlikely at this point. There are free PPPs and there will continue to be free PPPs. You will also more likely buy PPPs as part of hardware you buy. 4.2 Is it possible to use PPP as link layer in ISDN? [Somebody] wrote: Is it possible to use PPP as link layer in ISDN? If yes, what about signalling? Do you need to combine PPP with the I.451 for basic call control? PPP over ISDN is described by RFC 1618. It promotes PPP in bit-sync or in octet-sync HDLC over ISDN B-channels, or PPP in X25 / PPP in Frame Relay over ISDN D-channel. 4.3 My ppp does infinite configuration negotiation. What's wrong? 4.3.1 [CABLE PROBLEM] Each other month somebody posts a question which essentially is the one above. It could, of course, be some very strange set of configurations options which get the ppp to never terminate the negotiation process (typical situations listed in further down). One other possibility was seen many times on the derivatives of public ppp for suns, namely pppd-1.01beta and dp-2.x. Detailed symptoms (from a posting on the net, I saw similar logfiles some months ago): Typical debugging log output: Dec 18 16:11:01 pppd[1694]: Starting ppp daemon version 1.0beta patchleve l 1 Dec 18 16:11:01 pppd[1694]: warning... not a process group leader Dec 18 16:11:01 pppd[1694]: pgrpid = 1694 Dec 18 16:11:01 pppd[1694]: popped stream module : ttcompat Dec 18 16:11:01 pppd[1694]: popped stream module : ldterm Dec 18 16:11:01 pppd[1694]: Using unit ppp0 Dec 18 16:11:01 pppd[1694]: hostname = Riga Dec 18 16:11:01 pppd[1694]: connect: ppp0 /dev/ttya Dec 18 16:11:01 pppd[1694]: fsm_sconfreq(c021): Sent id 1. Dec 18 16:11:01 pppd[1694]: Timeout 6194:16b38 in 3 seconds. Dec 18 16:11:01 pppd[1694]: Setting itimer for 3 seconds. Dec 18 16:11:04 pppd[1694]: Alarm Dec 18 16:11:04 pppd[1694]: fsm_sconfreq(c021): Sent id 2. Dec 18 16:11:04 pppd[1694]: Timeout 6194:16b38 in 3 seconds. Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds. Dec 18 16:11:04 pppd[1694]: Setting itimer for 3 seconds. Dec 18 16:11:07 pppd[1694]: Alarm Dec 18 16:11:07 pppd[1694]: fsm_sconfreq(c021): Sent id 3. Dec 18 16:11:07 pppd[1694]: Timeout 6194:16b38 in 3 seconds. Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds. Dec 18 16:11:07 pppd[1694]: Setting itimer for 3 seconds. ... [lots of repetitious logging deleted] ... Dec 18 17:02:24 pppd[1694]: Alarm Dec 18 17:02:24 pppd[1694]: fsm_sconfreq(c021): Sent id 254. Dec 18 17:02:24 pppd[1694]: Timeout 6194:16b38 in 3 seconds. Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds. Dec 18 17:02:24 pppd[1694]: Setting itimer for 3 seconds. Dec 18 17:02:26 pppd[1694]: Hangup Dec 18 17:02:26 pppd[1694]: Untimeout 6194:16b38. Dec 18 17:02:26 pppd[1694]: Setting itimer for 0 seconds. Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ldterm Dec 18 17:02:26 pppd[1694]: str_restore: pushed module ttcompat Dec 18 17:02:26 pppd[1694]: fcntl(F_SETFL, fdflags): Bad file number The above final is caused by sending a SIGHUP to the pppd process (however three successive SIGKILL's seem to be necessary to really get rid of it). The warning "not a process group leader" appears to be the innocent result of a subtle coding bug, with no later effects, but I haven't tried fixing it (variable "pid" uninitialized). During all this, there seems to be no activity on the serial line, as evident from an Interfaker(tm) breakout patch box. I was desperate enough to lower the speed to 50 bps in order to verify this. At the same time, "netstat -i" does show increasing figures for the ppp0 interface in the "Opkts" column, but in no other column. Solution: in all cases I could solve, it was a case of missing modem control lines in the cables, leading to 'cts' floating to 'false'. The LCP FSM happily sent configuration requests (they went to the serial line driver buffer (and not out)), waited for an answer, got none, timed out, and retried. After lots more of retries, especially on a big machine, the send buffer finally does overflow, and ppp stops with an error message. You just have to connect 2,3,4,5,6,7,8 and 20 to the modem to repair it, or to wire a reasonably complete null-modem cable. No, there is no software hack, except when you patch the sources yourself. And that would be a bad idea in my opinion. Even a small Sparcstation SLC can overload any modem on a serial line, and you would get lots of unnecessary packet drops because of that. i.s. 4.3.2 [ADDRESS CONFIGURATION ERROR] Each other month somebody posts a question which essentially is the one above. It could, of course, be some very strange set of configurations options which get the ppp to never terminate the negotiation process, but this seems unlikely. This does happen under dp-2.3 [and probably others, i.s.] when both sides of the link have differing opinions as to what the 2 IP addresses should be. If the remote-address offered from the remote side doesn't match the locally configured version then dp-2.3 will send back an REJ packet. The remote side will then resend the original address again and the loop will continue. To see if this is the case check the log for address REJ's. Then decode the two hex addresses and print it out in the normal dot notation. This is the IP address pair of what dp-2.x expected and what it got. Now either reconfigure dp-2.x to expect this address or change the address that the other side is sending. Wolfgang Rupprecht 4.4 What is Asychronous HDLC? It's HDLC with a character-by-character encapsulation, rather than a bit-by-bit encapsulation. The details are discussed in the RFC1331, appendix A. Basically, the flag character, the escape character and (possibly) control characters are escaped by prepending the escape character and XORing them with 0x20, while sync hdlc transparently inserts '0' bits after sequences of 5 '1' bits to be sure to never transmit the flag character in the frame. A short description of the part of ISO 3309:1991 that describes async (ISO calls it start/stop mode) HDLC is available with anonymous ftp from ftp.uni-erlangen.de in pub/doc/ISO/english/async-HDLC. 4.5 My ppp gets strange configure rejects. What's wrong? Every few days, s.b. posts a similar question, which melts down to the above, when you look at it. The symptoms are, e.g.: Feb 6 09:04:08 steffi ppp[232]: demuxprotrej: Unrecognized Protocol-Reject for protocol 29801! Feb 6 09:04:09 steffi ppp[232]: demuxprotrej: Unrecognized Protocol-Reject for protocol 67! Feb 6 09:04:09 steffi ppp[232]: demuxprotrej: Unrecognized Protocol-Reject for protocol 15405! Feb 6 09:04:11 steffi ppp[232]: demuxprotrej: Unrecognized Protocol-Reject for protocol 15405! ... Pre-ppp-2.1 implementations (I think); this includes dp-2.x and probably early dp-3.x'es are too stupid to detect the old (RFC1172) vs. new (RFC 1332 and later) format of VJ compression, although it differs in the length and the length is explicit in each option. They tend to be off by 2 bytes after seeing such an option, and doing horrible things to logfiles, like the cited ones. dp-2.x users should use DP_ARGS=vjmode,draft for talking to nearly everything, or switch to ppp-2.1.2 if they don't need autodialup in the next few months. The faulty side is the other one. i.s. -- -- Ignatios Souvatzis - Solaris 2.1: it's slow, needs 200M of disk space and comes without C compiler, which makes it remarkably close to MS-Windows. oleg@gd.cs.csufresno.edu